Should this be its own PR to allow for discussions unrelated to adding the directory + template here and not intermix them?

Done

plural

"one or more use cases"

i think a jira link here is still valid assuming it is public.

justifying the work is not the purpose of the links imho. they are to add context or history to the work.

lets consider a checkbox approach ?

Who would we want here - Users, Maintainers (maybe split by project), Podman Desktop, CRI-O, Other... Anything I'm missing?

PD, CRIO, C/S, C/I, Common, Skopeo, Buildah, NV/AV, and other?

i think you jumped from one # to three?

i dont think this is important (here)

how should 'committed' be defined here? I'm thinking merged? And speaking of which, whats the policy of 'this doci s good'? Today, that's me as architect. im thinking it needs to be core maintainers but not ALL of them.

thought would be three core maintainers when authored by a non-core maintainer. And two when it is. probably should cross ref this in GOVERNANCE.md as well

Committed == merged, I'll clarify. I think we probably want at least 1 core maintainer to approve (maybe 2) plus at least a decent number of maintainers of the repo in question?

I would say at least one maintainer of the repo in question should approve and one core maintainer, bigger changes should be reviewed from ore people though. Depends on the complexity.

I think one important thing I would say here though is that the PR should stay open for at least a week to give time for others to actually provide feedback in case someone likes to object or has better ideas.

Also I think we need to set expectations then, i.e. a maintainer should not be allowed to block the merge of a PR implementing the functionality as described in a design doc if said design docs was approved by other maintainers. The time to object is at the design phase. Of course there are still valid reason to block implementation wise if it has major issues or doesn't do it as was described in the design doc.

Are we growing to be such a big project that we need to be building heavy formal processes, with assignment and approvals and deadlines and specific processes to change our minds? (I don’t know, maybe we are.)

As a possible alternative, I’d offer the w3c “explainer” practice, which focus more on “what we want to build, why, and we think how it is going to be used”, as a consensus building mechanism (where, in practice, some explainers end up not being fully implemented, and features may arrive without explainers) — rather than primarily an approval / gating / permission mechanism.

It's a fair point, I think if we want to welcome non RH maintainers and invite outsiders to participate then I think we should define some form of rules for clear expectations. I don't think they must be that strict certainly.

For now I see this primarily as a way to get our internal design docs public instead and have a feedback period.

Do we need an assignee field to make sure who works on this implementation if it is accepted? Doesn't mean anyone must work on it ASAP but I think we need to have a OWNER who is reasonable to get it completed.

And then I guess we need a completed field? Or we git rm the doc instead? I think removing the docs out of the repo makes sense to ensure only active stuff is visible in the repo.

IMO, git rm the doc. It's still in the history if we need it, no reason to clutter.

when would it be removed? once the feature is merged, released? I think merged?

thinking about this more ... suppose we have a design doc as a PR, and the person starts working on it while its in review (common practice). And it takes some time to get the PR reviewed and merged, and then immediately the PR for the actual implementation comes in. As soon as that is merged, we are saying git rm. Are we OK with such a short lifespan?

I would delete on feature merge yes. I mean it is in the git history forever for anyone to look it up so I don't think that is a problem.

If we're really concerned, maybe provide a list of removed docs and the commit that removed them in the README?

Special considerations for podman-remote / podman machine? I think that might be an aspect that’s easy to overlook, and these kinds of templates work well as reminders.

i also was thinking about this. And I decided to pass it but given that you are mentioning it, i think its probably prudent and I wasnt so far off base in my original thinking. So agree

Are we growing to be such a big project that we need to be building heavy formal processes, with assignment and approvals and deadlines and specific processes to change our minds? (I don’t know, maybe we are.)

As a possible alternative, I’d offer the w3c “explainer” practice, which focus more on “what we want to build, why, and we think how it is going to be used”, as a consensus building mechanism (where, in practice, some explainers end up not being fully implemented, and features may arrive without explainers) — rather than primarily an approval / gating / permission mechanism.

I like the overall idea that there is a single public-place listing all the features we are working on. I'm also +1 for general discussions about the ideas in the PR, but for any future design docs or architecture document, I think we should go with google docs and link the doc in the feature.md. It is much easier to comment/suggest/edit the google doc than collaborating on .md file in PR.

If that's how you think this process should work, maybe mention it explicitly in the template.

We can't do google docs that are completely open for public comment, so I think we want to collaborate on Github for these. Though I think it's perfectly fine if we do a private Google Doc for an initial pass and then propose the version that has already been discussed here.